移动可用性测试流程和常见问题

App-usability-testing-600x272

前言

移动互联网时代,针对移动产品进行的可用性测试,主要是将PC产品可用性测试方法和经验照搬过来。但在实际的工作中,由于移动产品的特殊性,我们遇到了一些在PC产品可用性测试中不曾遇见的问题,例如“使用测试设备还是用户设备”,“选择iOS平台还是Android平台测试”,“使用什么原型工具和记录工具”等。

因此,移动可用性测试的方法、设备、工具等都需要因“移动”制宜。我们尝试将移动可用性测试的零散知识总结梳理起来,加上我们的思考和探索整理成文,供大家一起交流。

本系列文章会分成4个部分:

  1. 移动可用性测试流程和常见问题(第一篇,即本文);
  2. 移动情境和移动设备选择(第二篇);
  3. 移动现场测试方法和工具(第三篇);
  4. 移动远程测试探索(第四篇)。

 

1.移动可用性测试流程

移动可用性测试流程与传统流程差异不大。但考虑到有读者可能是刚接触可用性测试,我们这里还是简单罗列一下。

  • 测试计划和招募(Prepare & Recruit)

    这是移动可用性测试最重要的阶段,这个阶段需要明确五大问题:为什么测试?在什么环境下进行测试?招募哪些对象进行测试?测试的系统和功能是什么?如何搜集和分析这些数据?对于这些问题,在内部需要讨论并达成一致意见。然后制定可用性测试计划,准备相关素材,包括制作测试原型、撰写测试任务和脚本、招募被试者、搭建测试环境和准备测试工具等。

  • 预测试和正式测试(Pilot & Test)

    移动可用性测试受到设备、环境、任务等多因素影响,进行预测试可帮助我们发现测试计划,及前期准备中可能存在的问题,从而保证正式测试的顺利进行。正式测试中,可以让设计师作为观察者,在便利贴上记录发现的问题,以便后续快速讨论输出。

  • 测试结果分析和输出(Analyze & Report)

    移动可用性测试需要采用轻量的方法进行分析并输出测试结果。如可以将记录问题的便利贴粘贴在墙上,快速讨论并组织达成一致意见。切记,这个过程是描述测试发现的问题,而不是产生解决方案。解决方案是下一步的工作。

  • 产品优化与迭代(Improve & Iterate)

    移动可用性的价值在于发现问题后的改善与优化设计。设计人员可以尝试回答这样一个问题:如何进行最小、最简单的优化,可以避免出现测试中发现的问题。然后进行测试,验证这种改变是否产生其他影响。

app-ut-01

 

2.形成性测试和总结性测试

根据测试的目标不同,我们一般将可用性测试分成两大类:形成性测试(formative test)和总结性测试(summative test)。实际工作中,我们做的大部分可用性测试都属于形成性测试,包括移动可用性测试。所以我们先澄清概念,后续对方法和工具的讨论,主要也都是围绕形成性测试展开。

这两个术语源自教育学,形成性测试主要在教学过程中进行,目的在于及时得到反馈来改进教学,总结性测试主要用于阶段性总结分析,目的在于全面考察学生阶段性的学习效果。

移动可用性测试中,我们通过形成性测试来发现产品设计研发过程中的可用性问题,及时修复,从而优化产品体验;在总结性可用性测试中,我们的目标是通过多个指标来评估产品的整体体验,通常在产品开发完成后进行。

从下表可以看到,形成性测试更关注如何快速地发现和解决可用性问题。不管是测试对象还是测试方法,包括被试样本数都倾向于比较轻量的解决方案。拿被试数量来说,一般参考Jacob Nielsen的经验数据要做5个左右。但是哪怕只有条件做1个被试,也推荐做一下形成性测试,因为做了就一定会有收获。

app-ut-02

 

3.移动平台选择

PC时代,我们几乎不用考虑平台问题,绝大多用户数都是Windows用户。但移动时代是多系统平台共存的时代,不同的平台(主要是iOS和Android)代表了不同的硬件,不同的用户习惯和交互方式。在Android上大家熟悉的设计语言,在iOS上可能会造成用户困惑。比如Android上的纸飞机发送按钮,iOS用户通常不认识。

app-ut-03

对于移动平台的选择,主要基于两点考虑,产品的平台分布情况,以及测试方法测试工具对平台选择的限制。

  • 平台分布情况

    App是iOS/Android双平台产品,还是iOS或Android单一平台产品;对于全平台覆盖产品,不同平台的后台用户数据占比是怎样的,是否有偏重,不同平台的用户是否有明显差异。

  • 测试工具限制

    当产品全平台覆盖,且并无明显平台差异时,测试工具的限制反而会成为选择平台的重要参考。如iOS系统对录屏的限制很多,当我们想拿到有些结果时可能不得不通过调研Android用户,从而得到想要的结果。本系列文章将在后续本地测试的工具部分,详细列出不同平台对应的用研工具。

 

4. 移动用户招募

和移动平台选择的问题类似,在移动用户招募中,也有一些需要注意的点。

  • 确保用户熟悉移动平台
    用户更换移动设备的频率远高于PC,且很有可能是Android换iOS,华为换小米的情况。移动设备的平台又比PC复杂,特别是碎片化的Android,每个厂商都有自己的系统(MIUI,Flyme,emui…)。所以除非要测试新平台的易学性,一般情况下,我们建议招募熟悉平台的用户来做测试,使用经验至少应该在3个月以上。这样可以确保用户在测试时,不会因为对平台的生疏而对结果造成干扰。
  • 确认移动设备
    一些用户可能拥有好几部手机和平板电脑。当筛选用户时,需要确保筛选问题是针对某个特定移动设备的。 例如,如果想研究在iPad上购物的用户,那么在招募时设定筛选问题时,应该是问:“你用iPad购物的频率是多少?”,而不是问“你在平板电脑上多久购物一次”。

 

5. 移动测试原型制作工具

PC/Web产品的原型工具很有限(如Axure),也并不完全适应制作移动原型。移动互联网之后,近两年移动交互原型工具不断涌现,移动的小界面使得原型效率提升,反馈周期缩短。类似POP这类移动制作原型的App的出现,可以用很低的成本,把纸面线框图转化为可交互原型,大大降低制作测试对象的成本,非常适用于项目早期的形成性测试。

我们在选择和比较制作移动测试原型的工具时,主要考虑了轻量,简单,多终端支持,支持远程分享这几点。综合对比之后,推荐使用Prott来制作测试原型。

app-ut-04

Prott支持Web和iOS双平台,虽然官网上也有Windows和Mac版下载,但都是内嵌网页实现的,所以体验一般。Web版通过拖拽的方式可以非常快速地完成原型工作,类似的产品还有Flinto(然而Flinto没有iOS原生应用);iOS版是原生应用,体验类似POP。

在有设计稿的情况下,用研同学可以独立通过Prott的Web版或iOS版独立完成测试原型制作。Prott也支持链接或者原型分享,可以远程分享给被测进行测试,在本系列的第四篇文章中会展开。

Prott的缺点。作为商业应用,Prott只支持一个免费项目,同时进行多个研究项目需要付费购买高级版本。当然也可以通过注册多个账号来解决这一问题。

 

文章来源:腾讯ISUX
顶部图片来源:https://www.appsee.com

 

 

发表评论

您的电子邮箱地址不会被公开。